1. Field of the Invention
The present invention relates generally to computer authentication using digitally signed certificates issued by certificate authorities (CA).
2. Description of the Related Art
Remote computer users can be afforded access to a secure network over the Internet by using digital certificates and public key/private key exchange principles. A protocol standard for effecting secure data transfer using these principles is the so-called Internet Engineering Task Force (IETF) Request for Comments (RFC) 2409 “Internet Key Exchange Protocol” (“IKE”), one embodiment of which uses a certificate standard known as the “X.509” standard. See “ITU-T Recommendation X.509 (1997E): Information Technology—Open Systems Interconnection—The Directory: Authentication Framework”, June 1997.
In IKE, two entities may generate and exchange cryptographic key data suitable for subsequent encrypted communication over a potentially unsecure network, e.g., the Internet. In essence, four messages are first exchanged, in accordance with Diffie-Hellman principles known in the art (U.S. Pat. No. 4,218,582, “Public key cryptographic apparatus and method”), between the entities, establishing a common symmetric encryption key that will be used to encrypt data during subsequent, secure communication.
Then, two further messages, encrypted with the symmetric key, are exchanged. These messages include signed certificates from each sender, as well as an identifier of each sender and a “cookie” that is transparent to the receiver. The certificate is packaged in a “certificate payload”, the signature in a “signature payload”, and the identifier in an “identifier payload”. The signature itself is derived from a hash of the identifier payload and cookie, with the result being encrypted using the private key associated with a public key in the sender's certificate.
Thus, after sending messages three and four, the keys that will be used to encrypt data for secure transmission are established, with messages five and six exchanging certificates of authenticity, so that each entity can be sure that the other entity is authorized to undertake the subsequent, secure data exchange. Since the details of the certificates and how they are verified in the X.509 certificate scheme is important to the present invention, a discussion of this follows.
Briefly, an entity such as a computer creates a public key and a corresponding private key using public key/private key principle known in the art, see “Applied Cryptography Second Edition: Protocols, algorithms and source code in C,” by Bruce Schneier, John Wiley & Sons, 1996. The entity then creates a request to be granted a certificate, where the request comprises an identifier for the entity and the public key. Next, the entity transmits the request to a trusted certificate authority (“CA”).
In response to the request, the CA creates a unique proto-certificate that typically includes the entity's name (and perhaps alternate names), a unique serial number, an expiration date of the certificate, the name of the issuing CA, and the entity's public key. The proto-certificate is signed by the issuing CA by applying to the proto-certificate a cryptographic hashing function such as the Secure Hash Algorithm (SHA-1) and then encrypting the resulting hash value with the CA's private key. The actual certificate is created by appending the digital signature to the proto-certificate.
To determine whether a certificate is valid, its expiration is first checked. If the certificate has not expired, its serial number is next checked against a list of revoked certificates that is published by the issuing CA, to ensure that the issuing CA has not revoked the certificate. If these two tests pass, the digital signature portion is decrypted using the CA's public key (which is assumed to be widely known). Then, the certificate (except for the signature portion) is hashed with the same hash function used by the issuing CA in generating the signature. Only if the resulting hash value matches the decrypted signature is the certificate deemed to be valid.
Simply possessing a certificate does not mean that the possessor is the entity to whom the certificate was issued. Accordingly, when a first entity presents its certificate to a second entity, the second entity uses the above process to ensure the certificate itself is valid. Then, the second entity generates a random number known as a nonce and sends the nonce to the first entity, which must encrypt the nonce with the first entity's private key and send the encrypted nonce back to the second entity. The second entity then decrypts the nonce with the first entity's public key that forms part of the certificate, and if the decryption is successful, the second entity may assume that the first entity is the intended possessor of the certificate.
In generating certificates for the above-described protocol, a single CA or a hierarchy of CAs operate in concert to issue certificates. When multiple CAs operate in concert it is usually in a “trust hierarchy”, wherein a first CA “trusts” the certificates issued by another CA. A hierarchy of trust ordinarily is established, with the most trusted CA at the root. As understood herein, if the root CA is compromised, the entire system is compromised. Likewise, if a CA that establishes a hierarchy node that is shared by two or more CAs below the node becomes compromised, the two lower CAs are also compromised. This is undesirable in a high security system. The present invention, in recognizing the above-discussed problem, offers the solution or solutions herein.